Personal Area Networks (PANs) are computer networks used for communication among personal computer devices, such as telephones, personal digital assistants (PDAs), etc., within a limited geographical area. In particular, a PAN enables communication between two or more communication devices within a range of a few meters. A PAN may be used for communication between the personal devices themselves (intrapersonal communication) or for connecting to a higher level network, for example the Internet, via an uplink.
PANs may be wired, for example via computer buses such as a Universal Serial Bus (USB), or wireless, for example utilising devices conforming to the ZigBee™ protocol, developed by the ZigBee Alliance (www.zigbee.org). The ZigBee protocol, in particular, is intended to provide a very low-cost, very low-power consumption, two-way wireless communication standard.
PANs may be used in a wide variety of situations, for example as part of home and building automation, industrial controls, personal computer (PC) peripherals, medical sensor applications, toys and games, etc. Typically, security measures are provided in order to maintain the integrity, etc. of the network and devices connected thereto. For example, the ZigBee protocol utilises keys, such as a link key, a network key and a master key, for encrypting messages transmitted between devices.
FIG. 1 illustrates an example of a known ZigBee network 100. The network 100 comprises a network controller 110, routers 120 and end devices 130. The network controller 110, routers 120 and end devices 130 are wirelessly coupled to form, for the illustrated example, a tree network topology. Each ZigBee device, that is to say each of the network controller 110, routers 120 and end devices 130, comprises a radio transceiver 802.15.4 stack, as defined in the IEEE standard 802.15.4 (www.ieee.org), and a ZigBee networking stack. The ZigBee networking stack provides functions such as network joining/leaving, authentication, end-to-end data transferring and routing, etc. The network 100 further comprises a trust centre (not shown), which typically is provided by the network controller 110.
In order to provide security, session keys in the form of network keys and link keys, are used to encrypt/decrypt messages transmitted between devices. A network key is used for encrypting/decrypting broadcast traffic throughout the network, and as such is the same for all communication devices within the network. Link keys are used to encrypt/decrypt uni-cast messages between two communication devices, and, as such, the link key is sometimes referred to as a symmetric key known only by the two communication devices participating in the end-to-end communication.
A ZigBee network further uses a master key, which is a shared key used during the execution of a symmetric-key key establishment (SKKE) protocol, and is the basis for long-term security between two communication devices, and is used to generate link keys. A detailed explanation of the SKKE process may be found within the ZigBee specification, available from the ZigBee Alliance (www.zigbee.org).
A ZigBee communication device may be pre-configured with the master key, for example during manufacturing. A problem with this method of providing a device with the master key is that the master key must be pre-determined, and cannot subsequently be changed. Accordingly, this approach is limiting and inflexible.
Alternatively, a ZigBee communication device may be provided with the master key by the trust centre upon joining a network. FIG. 2 illustrates an example of a message sequence chart for a communication device joining a ZigBee network, as is known in the art.
The joining device 215 begins the joining procedure by transmitting a beacon request command 220. Nearby routers 210 of ZigBee networks 200, upon receipt of the beacon request command 230, each transmits a beacon 225 comprising network layer specific information.
The joining device 215 then decides which network to join from the beacons transmitted by nearby routers 210, for example based on security attributes and the like identified within their respective beacons 225. Having decided which network to join, the joining device 215 sends an association request command 230 to be sent to the appropriate router. Upon receipt of the association request command 230 from the joining device 215, the router 210 then sends an association response command 235 back to the joining device 215.
Following the association response command 235, the joining device 215 is considered to have ‘joined’ the network, but is yet to be authenticated. The trust centre 205 of the network performs authentication. If the router 210 is the trust centre 205, authentication is performed immediately upon the new device joining the network. However, if the router 210 is not the trust centre 205, as is the case in the example illustrated in FIG. 2, the router 210 sends an update-device command to the trust centre 205.
Upon receipt of the update-device command (or where the router 210 is the trust centre 205, upon the completion of the joining procedure), the trust centre 205 decides whether to accept the communication device into the network. The decision to accept a new device may be based on various factors, such as whether the trust centre 205 is in a mode that allows new devices to join, whether the joining device 215 is eligible, for example as identified by an address of the joining device, to join the network, etc.
The authentication procedure depends on various factors, such as whether the joining device 215 has been pre-configured with a master key. If the joining device 215 has not been pre-configured with a master key, the trust centre 205 sends a master key to the joining device 215 using a transport-key command. As illustrated in FIG. 2, in the case where the router is not the trust centre 205, the transport-key command is secured between the trust centre 205 and the router 210, for example encrypted using the network key. However, in a case where the joining device 215 is not pre-configured with either a network key or a master key, the transport-key command must be sent from the router 210 to the joining device 215 unsecured.
Having conveyed the master key from the trust centre 205 to the joining device 215, via the transport-key command, the trust centre 205 and joining device 215 perform a symmetric-key key establishment (SKKE) procedure using the master key to establish a link key for the subsequent encryption of messages between the trust centre 205 and the joining device 215. Once again, and as illustrated in FIG. 2, whilst the SKKE commands are secured between the trust centre 205 and the router, they are unsecured between the router 210 and the joining device 215.
Once a link key has been established between the trust centre 205 and the joining device 215, the trust centre 205 sends the network key to the joining device 215, by way of a transport-key command 245 which is secured using the link key. In this way, the network key is securely transmitted not only between the trust centre 205 and the router 210, but also between the router 210 and the joining device 215.
Once the joining device 215 has received the network key, the joining device 215 is considered to be ‘authenticated’ 250.
A problem with this approach of remotely providing a Zigbee communication device 215 with the master key, is that the master key must be transmitted to the Zigbee communication device 215 in an unsecured manner. The ZigBee standard cites that implementers of a ZigBee network should note that transmission of an unsecured key represents a security risk and that if security is a concern, the keys should be pre-configured. However, as previously mentioned, pre-configuring of keys is limiting and inflexible.
In particular, the unsecured transmission of the master key may enable malevolent devices to obtain the master key, and thereby decrypt subsequent SKKE commands and transport-key commands. In this manner, a malevolent device would be able to obtain the network key and link keys, effectively nullifying the security of the network.
Another problem that has been identified with wireless PANs, such as a ZigBee network, is that such networks only utilise one-way authentication. For example, for the ZigBee network illustrated in FIG. 1 and FIG. 2, although the trust centre authenticates a device joining the network and, as a part of the decision to accept the device, provides some method of authenticating the device joining the network, the device joining the network does not perform any authentication of the trust centre, or the router with which it is communicating. Consequently, a rogue router may join a network, for example by obtaining network and master keys as described above, and by monitoring traffic within the network, mimic a trust centre for that network, and thereby cause disordering within the network. Disordering a ZigBee Network might be caused by any of the following:                Routing the traffic to a rogue (improper) PAN        Joining attacker devices        Disconnection of a ZigBee Application devices        Sending a device irrelevant or incorrect commands        
Thus, there exists a need for a method and apparatus for authenticating a network device, which addresses at least some of the shortcomings of past and present authentication techniques and/or mechanisms.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help improve understanding of various embodiments. In addition, the description and drawings do not necessarily require the order illustrated. Apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the various embodiments so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein. Thus, it will be appreciated that for simplicity and clarity of illustration, common and well-understood elements that are useful or necessary in a commercially feasible embodiment may not be depicted in order to facilitate a less obstructed view of these various embodiments.